Cream of the Crop 3/Cream of the Crop 3.iso/comm/aprs30_2.zip/README.RPT

Text File | 1993-10-26 | 10KB | 160 lines

            AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS

     To satisfy the objective of instantaneous response, APRS stations are
designed to begin operating without any prior knowledge of the network.  For
this reason, all APRS stations are initialized with the digi alias of RELAY
and to send all UI frames via the path of RELAY.  This way, a mobile, or new
station on the air does not have to know anything about the network in advance,
but to simply turn on his computer to be seen by adjacent nodes.  After 10
minutes and his map begins to show the location of all stations and digipeaters
on frequency, he can customize his outgoing Unproto path to specific
digipeaters to cover his intended area.

     Although digipeaters work poorly for AX.25 level 2 connections, they are
ideal for APRS operation using UI frames only.  In the Washington DC area and
Chesapeake Bay area, we are establishing a network of WIDE area DIGI's on the
simplex packet frequency of 145.79.  This frequency is for Keyboard QSO's and
all UI frame applications.  Operation of BBS's, forwarding, file transfers,
TCP-IP and DX clusters are discouraged.

     To make these WIDE area digipeaters respond to mobiles and new stations,
all wide area digipeaters have the same alias of WIDE in addition to
their normal HAM callsign.  These wide area Digi's are spaced several tens of
miles apart so that they are not too close, but that they can hit their
adjacent other WIDE digi's.  Assuming WIDE area digipeaters are about 30 to 50
miles apart it is very easy to select an UNPROTO path prior to a road trip
which will assure that your location packets will always get back to your home
area.  The following example shows a string of digipeaters along the east
coast.  The HAM calls of SOUTH and NORTH are used for clarity.

CALL:   NORTH-3    NORTH-2    NORTH-1   HOME-0    SOUTH-1   SOUTH-2   SOUTH-3
ALIAS:   WIDE       WIDE       WIDE     RELAY     WIDE      WIDE      WIDE

    If the mobile is going south for the day, and will be operating in the
vicinity of SOUTH-3 digipeater, the operator can preset his UNPROTO path to be
via WIDE,SOUTH-2,WIDE.  Notice that not only will his packets make it back to
home from the area of SOUTH-3, but also from the area of SOUTH-1 since SOUTH-1
will also respond to the first WIDE in the list.  Similarly, stations in the
vicinity of SOUTH-3 are alerted to his movements as he leaves home, since the
WIDE,SOUTH-2,WIDE specification is symetrical.  If he set the UNPROTO path to
SOUTH-3,SOUTH-2,SOUTH-1 in the usual manner, he would not be tracked at his
home until he actually arrived at his destination.  As you can see, having the
flexibility to alternate the generic alias's of RELAY or WIDE with other
known sites gives a good degree of flexibility without having to change the
UNPROTO path while on the road.  Using the three digipeater string, he can
wander up to 150 miles in his planned direction and still be tracked by the
XYL.  If he has no idea where he is going, he can always use the path of
WIDE,WIDE or even WIDE,WIDE,WIDE and go anywhere, but with greater QRM on the
channel.  Yes there are multiple collisions, and repeats, but the packet does
get out to the third tier!

   The ultimate APRS digipeater configuration is to have modified TNC-2
digipeater code so that any digipeater hearing a UI frame with its callsign
anywhere in the UNPROTO path will pause for a reasonable time and then
digipeat the packet as long as it was not previously digipeated by any
stations earlier in the list.  This way, to always report your movements back
home, you always place digipeaters in your UNPROTO command in the reverse
order of your travels.  Your packets will be digipeated back to your home area
as you enter each new digipeater in your direction of travel.  For example, if
you live in the vicinity of DIGI-1 below and routinely travel in the direction
out to and including DIGI-3.


     DIGI-1    DIGI-2    DIGI-3    etc

     If we can get TAPR to modify the code, the mobile could specify the
UNPROTO path of VIA DIGI-3,DIGI-2,DIGI-1 in order to be tracked anywhere all
the way out to the area of DIGI-3.  If only DIGI-1 hears the packet, it will
pre-emptively digipeat the packet and set its digipeat flag.  If DIGI-2 also
hears the original packet, DIGI-2 will pause for P seconds to see if DIGI-1
repeats it.  If so, it does nothing, since DIGI-1 follows it in the list.  If
not, after P seconds, it digipeats the packet for DIGI-1 to subsequently
further digipeat in the normal manner.  Similarly, DIGI-3 pauses for 2*P
seconds to see if DIGI-2 digipeated the UI frame.  If so, it does nothing.  If
not, after the 2*P seconds, it digipeats the packet.  Even if the packet pauses
and comparisons are not performed, (to simplify the code) the worst case is that
N duplicates will arrive at the destination for all N digipeaters that
simultaneously heard the original UI frame.  Since these are UI frames, any
pauses in the network for the comparisons suggested, are not significant.  The
extra code to do the pauses and comparisions only protects against duplicates
when two digipeaters hear the same original packet, and might not be worth the
extra code.

     This algorithm works perfectly well in reverse.  If a mobile desires to
announce his progress forward in the direction of his travel he can specify
the digipeaters in the forward direction.  Then using this algorithm, all of
his packets will be repeated in the forward direction, no matter where he is
along his route, but not in the backward direction.

     Until we get new UI forwarding algorithms in standard TNC's, however,
the general aliases of WIDE and RELAY will do nicely.  If fixed, known
digipeaters are available, even with the generic alias of WIDE, it is best
for fixed APRS stations to use the digipeaters unique callsign instead of
alias to avoid any ambiguity.

TheNET CONSIDERATIONS:  I now understand that G8BPQ TheNET code for the
DataEngine includes a DIGIon command that if set to 255 will permit
Digipeating of UI frames only.  Hopefully, other TheNET writers will include
a UI frame only digipeat command.  The problem, however, is that since the
digipeat ALIAS is the same as the NODE alias, you cannot operate a NODE with
the ALIAS of WIDE or it will totally screw up the NODE functions.  We are
asking John to consider permitting another ALIAS for UI frames only.

     Since NODES are so much smarter than digipeating, the ultimate solution
is to have the NODES do all UI frame routing.  The APRS station simply sends
his UI frame TO APRS VIA HOME;  Any NODE hearing that transmission that has
knowledge of the route to HOME, will send the single packet via the NODE
network (internode, level 4) to the HOME node!  When it arrives at the HOME
node, it is transmitted once as a UI frame.  With this arrangement, a mobile
only has to specify his one intended destination, no matter where he travels!

     P.S.  It would also be helpful if the INITIAL node hearing his level 2 UI
frame also digipeated it locally once so that the local area would also see
his position.  This could be made a user option, as follows:  If the
node had the generic WIDE alias for UI frames only, then the initial report
would be digipeated locally in the normal manner.   The first NON-WIDE field
would then be assumed to  be the ULTIMATE HOME node destination to be forwarded
through the network.  This way the mobile could decide whether he wanted to
be repeated locally (including WIDE), or just forwarded only...  To complete
this algorithm, NODES hearing the digipeated UI frame off of a WIDE digi,
should NOT enter the packet into the network, because MANY nodes will probably
hear the digipeated packet and only the first one should be repsonsible for
doing the level 4 routing..

     Finally, since I hope to build a region area Tracking network, the node
should also permit the SYSOP to turn off all other level 4 routing!  If we put
up a fully connected network of APRS nodes for tracking, we will soon be
swamped by all of the BBS and other file forwarding junk, and the network will
be defeated.  (of course, if this was included in all NODES, then we would not
need a dedicated tracking network, since APRS position reports could transit
all networks!)  Time will tell.  These few paragraphs were primarily written
to the NODE CODE writers such as John G8BPQ etc.  But are included here in
general distribution for all to read.

     As of version 2.12, APRS now has a special command (Shift-F1) that sets
ones own station to the ALIAS of WIDE vice RELAY.  This is so that an APRS
station that is well situated, can serve as a WIDE digipeater.  This special
command is used to override the automatic TNC initialization routine that
always sets APRS TNC's to the generic alias of RELAY.  This command should be
used with caution and the underestanding of all stations on the net.  Too many
WIDE's and too close together causes too much QRM.  The command has to be
used each time APRS is run, since the initialization routine will always reset
your alias to RELAY.  Also, if you use the Shift-F1 command, your symbol will
be set as a digipeater and the word WIDE will be installed in your POSIT
comment field so that your station will show up on all screens as a green star.
This symbol and color of a digipeater will be lost, however, if you have a
weather station hooked up to your station, since it re-writes the POSIT string
every few minutes.

SEE README.HF for setting up your UNPROTO path for HF and HF/VHF gateways..


FINAL NEWS FLASH:  PACCOM has included a GPS ON command in all version 3.1
firmware for thier TNC's.  This command permits their TNC to take the NMEA-0183
output of any GPS device and place the GPS position data in the TNC Beacon
text.  With this capability, anyone can build a GPS tracking device for APRS
with nothing but a GPS and a PACCOM TNC.  See the README.GPS file.  Hopefully
PACCOM and other manufacturers will then begin to work on the digipeater
and TheNET routing solutions for UI position reports!